Newer processors for a variety of applications are available with multiple thread capability with a single core and with multiple processing cores. Each thread or core is able to operate on one set of instructions while another thread or core independently operates on a different set of instructions. Currently, multiple threaded and dual core processors are readily available and may be deployed in multiple processor architectures, so that, for example two dual core processors present four independent processing cores. Future processors may have four or more cores in one chip. In order to take full advantage of each core, there must be some way to determine which tasks will be performed by each processor. In one model, the tasks to be performed by the computer are divided into threads, each core will execute all of a single thread, and then move on to another thread. Multiple threading, single or multiple core processors operate similarly executing threads in turn.
As multi-core architectures become more common, multithreaded programming may become part of mainstream applications. STMs (software transactional memory) are under consideration for easing multi-threaded programming. Emerging HPCS (High Productivity Computing Initiative) languages, such as Fortress, Chapel, and X10, rely solely on transactions for synchronization. These languages rely on a STM for implementing the transaction construct; and the transaction construct in these languages has sophisticated semantics. This makes the STM very important.
Software transactional memory (STM) is a concurrency control mechanism for controlling access to shared memory in multi-threaded computing. A transaction is referred to as an object and represents a series of instructions that executes a series of reads and writes to memory that is shared by the multiple threads. These reads and writes logically occur at a single instant in time in that intermediate states are not visible to other transactions. The object-based structure of STM allows for familiar object-based programming constructs to be used.
Transactions may also be supported in some fashion by special hardware added to a multi-core design. Limited hardware support for transactions is available in some current products. However, a STM may still be required to execute transactional code that cannot be handled in the hardware. As a result, the hardware TM (transaction manager) system is virtualized and an application does not have to bother about size limitations, etc. This also relies on a high-performance STM.
To resolve conflicts in a STM, a cache line-based conflict detection, or some form of hashing scheme is currently used to detect conflicts between transactions. This creates false conflicts between transactions and is less intuitive for the programmer, since the programmer is programming in terms of objects. At the other extreme, word-based conflict detection without aliasing represents too much overhead for an STM, although such schemes have been proposed for HTM (hardware transactional memory). Cache-line or hashing based schemes do not allow the compiler to perform CSE (Common Sub-Expression Elimination) and other redundancy removal in STM code, causing a significant limitation in speed.